![[レポート] AWS 環境をコードで管理する ～コード化の開始から頻出パターンまで～ #AWSSummit](https://devio2023-media.developers.io/wp-content/uploads/2018/04/400x400.png)
[レポート] AWS 環境をコードで管理する ～コード化の開始から頻出パターンまで～ #AWSSummit
5/30 から 6/1 まで、東京・品川で開催されております AWS Summit Tokyo 2018。こちらで講演されたセッション「AWS を使った動画配信入門」を聴講しましたのでレポートします。
5/30 から 6/1 まで、AWS Summit Tokyo 2018 が東京・品川で開催されました。こちらで講演されたセッション「AWS 環境をコードで管理する」を聴講しましたのでレポートします。
今回のAWS Summitでは全セッションにて撮影が禁止されておりました。資料は後ほど公開されるとのことでしたが、いまのところは文字だけのご報告となります。
概要
AWS 上に構築したシステムは、従来と同じように手順書を使って人が操作できる一方で、全ての操作をコードで記述し自動化することも可能です。開発と運用をコードで自動化することで、システムに何が起きるのか？ コードを書くならどこから始めたら良いのか？ 自動化でよく使われるパターンはどんなものか？ このセッションではコマンドラインツールである AWS CLI、構成管理サービスである AWS CloudFormation の最新情報を中心に、コード化の第一歩の始め方と、AWS で開発と運用を自動化する際の頻出パターンを解説します。
スピーカ
- 大村 幸敬
- アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
- エンタープライズのお客様担当
※敬称略
レポート
Agenda
- クラウド運用のベストプラクティス
- クラウドの構成管理
- Tips & Tricks
- CFn + CLI
- コード化の頻出パターン
- アンケート
- アプリケーション開発、インフラ構築 多い
- 運用 そこそこ
ベストプラクティス
- “Are you Well-Architected?” Werner Vogels
- その運用は Well-Architected (W-A) か？
- アプリケーション
- アジャイル開発
- インフラ
- クラウドで初期等しなく迅速に変更可能
- 運用
- 申請書と手順書と... -> NG !
W-A Operational Excellence
- 原則
- コードを使って運用する ←ここについて話す
- 他に気をつけたいこと
- 注釈付きドキュメントを自動生成する
- 頻繁に、小さく、可逆的に変更する
- 運用手順を頻繁に見直す
- 等
コードを使った運用のポイント
- コードで全ての構成を定義
- 同じ環境を、迅速に、繰り返し作成可能
- オンプレ = 作るのに時間がかかる = Feedbackが遅い
- クラウド = まず作ってFeedbackを得て作り直す
- 変更は「秘伝のタレ」になる
- (変更していくのでは無く) 一からクリーンに作った方がいい
- 早く作ってリファインしていくことができる
- イベント(発生した事象)に対してスクリプトで対処
- 自動的に、同じ処理を、繰り返し実行可能
- CloudWatch Event
- 定期イベント
- イベントドリブン
- アプリケーションと同じ手法でコードを開発
- コードと作成した環境の品質を担保
クラウドの構成管理
- 全ての構成変更はサービス利用者に影響
- 初期構築で終わりではない
- 利用者に影響のある変更は全て「変更」である
- インフラとアプリで分けるのでは無く、全体を見る
- AWS環境に対するオペレーション方法
- App+設定、デプロイ = 手作業・自作スクリプト／CodeDeploy
- MW設定、OS設定 = 手作業、Chef、Ansible
- EC2 + 設定、VPC =
- マネジメントコンソール（手作業
- CLI
- CFn
- Terraform
- AWSのプロビジョニングサービスのカバー範囲
- ElasticBeanstalk、OpsWorks、CodeDeploy、CFn
- サービスのカバー範囲を超えた部分は「動くけど無理してる = 黒魔術」
- デプロイ対象による範囲の違い
- EC2、Fargate、Lambda
- コンテナはなぜ良いか = 管理しないとならない範囲がコンテナだけになるため
- ECSだとEC2の管理が残っていた = Fargateが解決
- APIへのアクセスとOSへのアクセス
AWS環境を管理するためのツール
- CFn + CLI
- CLIとCFnを使ったAWS環境操作の流れ
- ひと -> MC/CLI -> AWS API -> リソース （※MC = マネジメントコンソール）
- スクリプト -> CLI -> AWS API -> リソース
- CFn -> CLI -> AWS API -> リソース
- AWS APIを何でたたくかの違い
- CFn
- AWS環境のコンフィグレーション管理サービス
- 作成
- テンプレートに定義された構成でスタックを自動作成
- 変更
- 差分を適用
- 削除
- CLI
- AWSのAPIと1:1で対応
- 実装はPython / boto3
- マネジメントコンソール(MC)と違い、コマンドはほぼ変更されない
- MCは頻繁にかわる = 手順書のスクリーンショットが古いまま
- MCのスクリーンショットを貼り付けて作った手順書は誰も幸せにならない！
- アップデートは頻繁
- CLIとCFnの位置づけ
- 相互補完
- CFn 状態
- CLI 操作
- 相互補完
Tips & Tricks
- 講演にあたり、掲載したい内容を大幅に削った
- 資料公開時にさらに増量される予定
- CFn Tips
- テンプレート開発のTips
- Docs リファレンス、サンプル、スニペット、オフィシャル
- IDE Cloud9を使うと便利
- シェル環境付き、キーワード補完
- パラメータ AWS Systems Manager ParamaterStore
- CFnテンプレートの Paramaters から直接利用可能
- AWSが提供する値、自身で設定した値
- 暗号化されたパラメータは「いまは」取れない
- 参考 : パラメーターストアから最新のWindows AMIのIDを取得する ｜ Developers.IO
- CFnテンプレートの Paramaters から直接利用可能
- Lint
- cfn-python-lint
- awslabsで公開されているOSS
- VS CodeやATOMのエクステンションあり
- cfn_nag
- 3rd partyのOSS
- cfn-python-lint
- スタックの分割
- 基本方針
- ライフサイクルが同じものは同じスタックに
- セキュリティ設定は別スタック
- ステートフルとステートレスの分離
- Cross Stack Referenceの活用
- 正解はない、自分たちで考えるべき
- 基本方針
- CI/CD for CFn
- テンプレート開発のTips
- CLI Tips
- インストール
- ヘルプ、TAB保管
- queryとエイリアス
- 長くなるコマンドはエイリアス設定しておくといい
- 参考 : AWS CLIにalias機能が追加されました ｜ Developers.IO
- CLI
- アクセス経路
- APIアクセスはインターネット経由
- VPCエンドポイントでプライベートアクセスが可能
- CLIの認証と認可
- 永続的 アクセスキー long-term access key credentials
- 一時的 一時的なアクセスキー
- 有効になる順番
- 環境変数 > credentials > config
- クロスアカウントアクセス
- source-profileに指定
- SAMLで認証してAWS APIへアクセス
- awslabs/awsprocesscreds: Process credential providers for AWS SDKs and Tools
- CLIでもMFA
コード化の頻出パターン
- マルチアカウント
- インフラチームはアカウントをまるごと開発チームに渡す
- インフラチームは固めるんでは無く「見守る」CloudTrail、AWS Config
- Organizationsでアカウントの払い出し
- アカウント環境の一括管理
- 複数アカウントへの展開 - CFn StackSet
- コンプライアンスイベント対策
- AWS Config + Lambda
- インスタンスを立ち上げるときのPendingをCloudWatch EventsでひろってLambdaがチェック
まとめ
- W-A Operational Excellence を読もう！
![[AWS CDK] Stack内の全てのリソースに対してRemovalPolicyを設定してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-5cf97530609f228b0c0aa35bb42ef118/177aae4f779b47783f481bd82859ff0b/aws-cdk)
